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(54) A method and apparatus for automatic updating of printer configuration and status data 



(57) A method and apparatus for updating print driv- 
ers is described. The described system includes a port 
monitor that monitors the configuration and status of a 
printer. When changes occur to the configuration of a 
printer, the port monitor updates a print driver registry 
on the print server. The port monitor also wakes the print 
driver on the print server and informs the print driver of 
the configuration changes. Depending on the client op- 
erating system used, a client device connected to the 



server's shared print queue may either directly read or 
request the configuration data from the print server. In 
some client operating systems, the client device may al- 
so update a local registry on the client device to reflect 
the changes in configuration of the printer The described 
system allows print drivers to have a consistent interface 
to printer configuration and status data regardless of 
which version of the Microsoft Windows Operating Sys- 
tem is used by the client. 



CM 
< 

CO 

o> 

CO 
00 



Q- 
LU 



Xerox TCP i IP Pnn Monrtnr for WWxtnwi NT 

Port Device hn» HSjSr 



5B 



440-^ 



434 



444 



44* 



430 

4a 



Port Mimgetnent «nd Data Flow Contml 













•Ml 




'JPBaK 













Part Mowrtct Printer Mugger 



J* 



4*4 



4& 



rata 

r th»i 



rpn Lrrl 



471 



Altd Pon Wirtfd and Port Coniiyglioii 













SET 



1 *nm\ 



Port MoartorAPl 



Window* Prrnl Spoolo 




470 

u 



464 
4}Q 



FIG. 4 



Printed by Jouve, 75001 PARIS (FR) 



BNSDOCIO <EP 1178393A2J > 



1 



EP 1 178 393 A2 



Description 

[0001] Print drivers have long been used to format 
and transfer computer data from a source of data such 
as a computer to an output device such as a printer. $ 
However, because printers from different manufactures 
typically have different software and hardware configu- 
rations, print drivers typically need to be customized to 
match the particular printer configuration. Users enter 
relevant data into the computer to customize the print 
drivers. 

[0002] User entry of printer customization data can be 
time consuming, and is prone to user error. Thus bi-di- 
rectional drivers that are capable of receiving and 
processing printer status and configuration data have 
been implemented. 

[0003] However, the most widely used operating sys- 
tem, the Windows operating system from Microsoft Cor- 
poration of Redmond, Washington, are not designed to 
support bi-directional drivers. Current implementations 
of bi-directional drivers in Microsoft OS systems circum- 
vent the spooler to enable data flow in two directions. 
Circumventing the spooler does not conform to Micro- 
soft specifications. Failure to conform to Microsoft spec- 
ifications creates problems regardless of the Windows 
operating system used. In Windows NT systems where 
many clients communicate to printers through a print 
server, the avoidance of the print spooler prevents the 
updating of printer information in the print server be- 
cause typically, only a system administrator may change 
the printer configuration settings in the printer server. In 
Windows 95 and Windows 98 systems that utilize a print 
server, the print server data Is not updated because Win- 
dows assumes that the print configuration data is local 
client data and thus fails to update the print server. 
[0004] Thus an improved bi-directional print driver is 
needed. 

[0005] In accordance with a first aspect of the present 
invention, a method of updating a print driver in a print 
server comprises gathering printer data, such as printer 
configuration and/or printer status data, from a printer 
at a printer port; 

monitoring the incoming printer configuration data 
for changes; 

recognizing the changes in printer data; and, 
saving the changes in printer data as summarized 
data in a spooler registry. 

[0006] In accordance with a second aspect of the 
present invention, a method of updating a print driver in 
a client device comprises gathering summarized printer 
data, such as printer configuration data and/or printer 
status data, from a printer at a printer port of a print serv- 
er; 

monitoring the incoming printer configuration data 
at the print server for changes in the configuration 



2 

data; and, 

updating a print server registry of the print server 
when a change in summarized configuration data 
occurs. 

[0007] In accordance with a third aspect of the present 
invention, a system to output printed documents com- 
prises a printer to output convert electronic signals into 
a printed document, the printer having a configuration 
state that corresponds to a particular period in time; 

a first client device that receives an input and trans- 
mits print signals to define a document to be printed 
on the printer, the first client device including a local 
print registry that maintains the configuration states 
of the printer; 

a second client device that receives a second input 
and transmits print signals to define a second doc- 
ument to be printed on the printer; and 
a print server coupled to the first client device and 
the second client device, the print server including 
a print server registry that maintains the configura- 
tion states of the printer. 

Brief Description of the Drawings 

[0008] Figure 1 shows a networked system including 
a client device that communicates with a printer through 
a print server. 

[0009] Figure 2 is a flowchart that illustrates operation 
of a bi-directional print driver in a data •push" configu- 
ration. 

[0010] Figure 3 shows a schematic view of possible 
data flows in a print provider. 

[001 1 ] Figure 4 shows a schematic view of a possible 
port monitor architecture including possible data flows 
for use in a Windows operating system. 
[001 2] Figure 5 shows one example of a possible user 
interface displays for setting up port information and bi- 
directional communication settings. 
[0013] Figure 6 shows a second example of a possi- 
ble user interface display for adjusting polling informa- 
tion used in monitoring printer status and configuration 
data. 

[001 4] Figure 1 illustrates a networked system includ- 
ing a printer 104 that is coupled to a print server 108. 
Print server 1 08 transfers data to be printed from multi- 
ple clients 108,112, 11 6 to printer 104. Print server 108 
also transfers printer data, including printer status and 
configuration data, from printer 104 to clients 108, 112, 
116. 

[0015] In order to control the flow of data, a local 
spooler program runs in each client 108, 112, 116. In 
one embodiment, the spooler program is part of an op- 
erating system such as Windows 98 or Windows NT 
from Microsoft Corporation of Redmond Washington. A 
user installed port driver in a port monitor interfaces with 
the print spooler to convert the data from the print spool- 
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er Into a format suitable for a corresponding printer. For 
example, when communicating with printers made by 
Xerox Corporation of Stamford, Connecticut, a Xerox 
TCP/IP port monitor may be installed on the server com- 
puter to enable formatting of documents to conform to 
a LPR or Port 91 00 protocol. The print monitor maintains 
data on printer configuration and printer status. Exam- 
ples of printer configuration data include information on 
printer set ups such as duplex information, tray and en- 
velope information that may indicate paper sizes and 
colors, preprinted header information on the paper and 
the like. Examples of printer status data include infor- 
mation on whether the toner is low or whether a paper 
jam exists in the printer For purposes of this application, 
the term "summary printer data" will be used to include 
both printer configuration data and printer status data. 
[0016] Single direction print monitors only allow data 
flow from the client computer to the printer. Thus up- 
dates to printer configuration or status are manually en- 
tered by the end user. As previously discussed, such 
data entry is prone to errors. Bi-directional print monitors 
enable a printer to automatically update monitor data. 
However, the Microsoft spooler architecture in Windows 
NT and Windows 98 was not designed to support bi- 
directional print monitors. Thus, in current embodiments 
of bi-directional print monitors operating in a Microsoft 
operating systems, the print device driver obtains the IP 
address of the printer and directly addresses the printer 
circumventing the operating system print spooler. 
[0017] Circumventing the operating system print 
spooler breaks operating system protocols for the cur- 
rent generation of Microsoft Windows operating sys- 
tems. Furthermore, circumventing the operating system 
print spooler creates additional problems in Windows 
NT networks that utilize print servers to maintain and 
monitor printer settings. In particular, when a print server 
is used to maintain printer settings, client computers 
connected to the print server are unable to change or 
otherwise update the stored printer configuration set- 
tings because typically only a print server administrator 
is authorized to change print server local configurations. 
[001 8] In order to implement a bi-directional print driv- 
er in a Microsoft Windows operating system and allow 
upgrading of printer configurations in a print server, one 
embodiment of the current invention utilizes a polling 
method of updating data. Figure 2 is a flow diagram il- 
lustrating the communication of data in a polling "push" 
architecture. In block 204, a poll device, which may be 
implemented in the port monitor, periodically transmits 
a request signal to the printer. A server administrator 
may set the time interval between periodic request sig- 
nals. Typical printer data requests may include, but are 
not limited to, configuration and printer status data. Ex- 
amples of printer configuration data include papertypes, 
paper size, paper finishes (glossy or matte), and enve- 
lope trays. Printer status data typically describe a state 
of printer operation. Examples of printer status data in- 
clude whether a printer is ready, that the printer is 



jammed, or that toner levels are low. In block 208, the 
printer transmits a response signal that answers the re- 
quest signal. The response signal provides the request- 
ed data. 

s [0019] In block 212, a processor compares the printer 
data received in response to the poll request with stored 
data from previous poll requests. If the polled data 
matches the stored data, no change has occurred, no 
control flags are set, and the system waits a preset time 

10 interval in block 214 before transmitting another poll re- 
quest. However, if the received data does not match the 
stored data, then a change in either printer status or 
printer configuration has occurred, and corresponding 
control flags are set in block 216. In one embodiment, 

15 a port monitor manager uses the control flag settings 
and the stored settings to direct future printer instruc- 
tions. In an alternate embodiment, the port monitor man- 
ager may wake up the print driver to effect the configu- 
ration changes as shown in block 220. 

20 [0020] When the polling device is implemented in a 
print server, the change in printer configuration or status 
may be "pushed" through the system. As used herein, 
the term "push" refers to transferring data back through 
the system from the printer to a print server, and from 

25 the print server to the client. In block 224, the print sever 
transmits printer configuration and printer status data 
changes to the client computers that originate printer in- 
structions. One method of communicating such chang- 
es is by transmitting control flags. 

30 [0021 ] In Windows NT operating systems from Micro- 
soft, the preferred method of informing the print driver 
of configuration changes is by using the Print Driver 
Event API which is defined and described in the Win- 
dows NT DDK (Device Driver Kit) published by Microsoft 

35 of Redmond Washington and which is hereby incorpo- 
rated by reference. In operating systems in which the 
server registry is not assumed to be the local registry 
clients request that a Pipe Server thread be used to 
transfer the control flags or updated printer data from 

40 the server registry to the client computers. Examples of 
operating systems in which the server registry is not as- 
sumed to be the local registry include Windows 95 and 
Windows 98. Thus, in the previously described embod- 
iment, client computers connected to the print server or 

45 a print queue automatically receive the updated set- 
tings. 

[0022] Figure 3 illustrates possible data flow paths 
from a Microsoft Windows NT client system 304 to a plu- 
rality of printers 306, 308, 310, 312. A detailed descrip- 

50 tion of the Windows NT print server architecture is pro- 
vided in the Windows NT DDK which was previously in- 
corporated by reference. An application, 314, typically 
software that generates text or graphics such as Micro- 
soft Power Point or Microsoft Word creates a document. 

55 Application 31 4 creates a print job by calling a Graphics 
Driver Interface 316 (GDI) as illustrated by data path 
318. Graphics Driver interface 316 creates a spool file. 
In specialized applications, the application program may 
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directly create spool file without using the GDI as illus- 
trated along data path 320. 

[0023] Most functions defined by print providers re- 
quire a printer handle as input. In an example Windows 
NT operating environment, the client spooler obtains a 
printer handle by calling a command OpenPrinter in the 
client Winspool.drv 322. The calling of the OpenPrinter 
command causes Winspool.drv 322 to call API server 
324 (spoolsv.exe). The capabilites of the spooler are de- 
fined by the API functions available. 
[0024] A client spooler router 326 (spoolss.dll in Win- 
dows NT) calls each print provider's OpenPrinter func- 
tion until one of the print providers supplies a printer han- 
dle and a return value indicating the print provider rec- 
ognizes the specified printer name. The printers called 
may be either local printers, remote printers running 
Windows NT and remote printers running other operat- 
ing systems. Local printers are called via a local con- 
nection using localspl.dll 328. Windows NT print servers 
may be called via a remote connection using Win32spl. 
dll 330. Print servers that utilize non Windows compat- 
ible operating systems may be called using other Pro- 
vider DLLs 332. Examples of Non windows DLLs sup- 
ported by a Windows NT and/or Windows 2000 client 
system include, but are not limited to, nwprovau.dll for 
Novell NetWare print servers and inetpp.dll for HTTP 
print providers that handle print jobs sent to a URL. 
[0025] A Kernel-mode or Port Driver stack 334 directs 
the open printer call from the client system 304 to local 
printer 306, to remote printer 307, to networked servers 
336, 338 coupled to corresponding printers 308, 310, 
and to Windows NT server system 340 coupled to cor- 
responding printer 31 2. Windows NT server system 340 
receives the remote procedure call interface (RPC) sig- 
nal 342 from the client system 304 al the remote print 
server router 344. The printer server router 344 gener- 
ates its own OpenPrinter function 346 that propagates 
through server Localspl.dll 348 and the print server Ker- 
nel-mode Port Driver Stack 350 to printer 312. 
[0026] The printer spooler router 344 calls each print- 
er's 312 OpenPrinter function until one of them supplies 
a printer handle and a return value indicating the print 
312 recognizes the specified printer name. The printer 
spooler router 344 then returns its own handle to the 
client system 304. The print router handle includes both 
the printer handle and the print server handle. This print 
router handle is returned to the application 314. The 
transferred handles allows application 314 to direct sub- 
sequent calls to the correct print server and printer. 
[0027] Figure 4 shows a port monitor architecture 400 
as implemented in one embodiment of the invention. In 
one embodiment of the invention, a server, using the 
port monitor of Figure 4, transmits inquiries regarding 
printer status and configuration to a printer using a poll- 
ing method. When a change in printer status or config- 
uration occurs, the port monitor updates stored printer 
configuration and status data in a registry of the server. 
Some client operating systems, such as Windows NT 



utilizes the server registry as the local registry. However, 
other client operating systems, such as Windows 9x se- 
ries operating systems including Windows 95 and Win- 
dows 98 maintain a separate local registry. In such sys- 

5 terns, the client may periodically poll the server to de- 
termine printer configuration and/or status changes. 
When such changes are detected, the client may re- 
trieve the printer configuration or status changes from 
the server via a server thread. 

10 [0028] Block 402 includes protocol support 404 hard- 
ware and software that receives streams of print data 
from each port ceil such as a first port 406 and a second 
port 408. Protocol support 404 converts the data into a 
print data stream that matches an acceptable printer 

15 protocol for output to a printer. Typical IEEE accepted 
protocols include LPR (Line print protocol), LPR with 
byte counting and AP Socket 91 00 although other pro- 
tocols may also be possible. 

[0029] Because the print system is a dynamic system, 
20 printers and clients may be added to the network. Block 
41 0 of Figure 4 includes components used to add ports 
to the print server. In block 410, Port Wizard software 
41 2 communicates with an auto printer discovery dy- 
namic link library (DLL) 414. Discovery DLL 414 utilizes 
25 discovery APIs 416 to determine attached or available 
printers. After determining available printers, Port Wiz- 
ard software 412 adds ports using add port subroutine 
41 8. Configure port subroutine 420 properly configures 
the added ports. When the print spooler 424 is part of 
30 an operating system, both the port management soft- 
ware of block 402 and the add port software of block 
410 use port monitor application program interfaces 
(APIs) shown in block 422 to format and transmit re- 
quests to the print spooler. When the operating system 
35 is a Windows operating system from Microsoft Corpo- 
ration of Redmond, WA, the port monitor APIs in block 
422 are Microsoft defined APIs used to communicate 
with the Windows Print Spooler. 

[0030] In Figure 4, Port Device Data Manager 426 in- 
terraces with a port monitor printer manager 428. In one 
embodiment of the invention, both port device data man- 
ager 426 and port monitor printer manager 428 are part 
of a print server that transfers information between a 
printer and client computers. 

^5 [0031] Port device data manager 426 includes a 
shared locked memory 430 that maintains configuration 
data, status data and control data for each printer cou- 
pled to the print server. A port manager API 440 man- 
ages communications with a printer using a standard 

so communications protocol such as SNMP. SNMP com- 
munication is controlled by a text based file containing 
printer information. An example of such a text base file 
is included in Figure 4 as "product config.ini" 442. A 
communications network or a corresponding Bidi thread 

55 such as first port thread 432 communicates configura- 
tion data 434 and status data 436 from the printer to the 
appropriate memory locations 438 in shared/locked 
memory 430. 
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[0032] One method of maintaining status and config- 
uration data is to continuously replace the stored con- 
figuration data and status data in memory location 438 
with newly received configuration data and status data. 
However, constant retransmission of all printer configu- 
ration and status data to all clients consumes excessive 
network bandwidth. In order to minimize retransmission 
of configuration and status data from the print server to 
client devices, changes in configuration data and status 
data may be summarized by setting appropriate control 
flags 444 that represent any changes in the configura- 
tion or status data. In one embodiment of the invention, 
shared locked memory 430 also stores the control flags 
444. 

[0033] The described communications network or first 
port thread 432 may be replicated for each port coupled 
to a printer. For example, Figure 4 shows a second port 
thread 446 that receives corresponding configuration 
data 448 and status data 450 from a second printer (not 
shown). A second memory region 452 of shared locked 
memory 430 maintains the configuration and status data 
as well as corresponding settings of control flags. The 
data in second memory region 452 may be used by the 
print server as well as retransmitted to client computers. 
[0034] Printer manger 428 includes a multi-tasking 
printer manger thread 454 that receives data from 
shared locked memory 430 of device port manager 426. 
The data may include configuration data, status data 
and/or control flags. Printer change notification thread 
456 tracks changes in printers coupled to respective 
ports of the print server. When the printer notification 
thread 456 is implemented in a Microsoft Windows en- 
vironment, the printer change notification thread 456 
may use standard Microsoft APIs to detect printer 
changes. Port printer manager 428 coordinates infor- 
mation from printer change notification thread 456 and 
Printer manager thread 454 with available printer data 
stored in printer list 458 and available port data stored 
in port list 460. Printers identified in list 458 typically 
have a corresponding entry in registry 468 correspond- 
ing to the printer. Each printer entry in printer list 458 
may include, but is not limited to, printer names, device 
ids, port names, port handles, configuration Ids, status 
Ids, and printer events. Port list 460 may include, but is 
not limited to data pertaining to each port such as port 
handles and previous control states. 
[0035] Print manager thread 454 summarizes data re- 
ceived from printer list 458, port list 460 and shared 
locked memory 430 and forwards the summarized data 
to a summarized data 469 area in printer registry 468. 
In addition, print managerthread 454 alerts printer driver 
462 of the changes. The print driver converts the sum- 
marized data 469 to an internal format 471 compatible 
with the print driver. The internal format data 471 is 
stored in a corresponding area of printer registry 468, 
The operation of a typical print driver is described in the 
Microsoft Windows NT DDK which has been incorporat- 
ed by reference. 



[0036] When client 464 is a client that maintains a lo- 
cal print driver and thus does not automatically assume 
use of a server print driver, (examples of such operating 
systems include Windows 9x clients referring to clients 

s computers that operate using Microsoft Windows 95 
and/or Windows 98) the client 464 requests that pipe 
server thread 466 retrieve summarized data 469. Pipe 
server thread 466 may perform or facilitate both client 
transmission of data request commands as well as pipe 

10 server thread 466 generated responses of configuration 
and status information. 

[0037] Some clients may utilize operating systems 
that assume the use of a print server driver as the local 
driver. One example of such an operating system is a 
15 Windows NT operating system. Each Windows NT cli- 
ent, such as client 470, may directly access data from 
registry 468. 

[0038] Figure 5 shows one example of a user inter- 
face that may be implemented for controlling bidirection- 
al communications. In screen 504, a summary 506 of 
port setting is provided. Any of these values may be 
modified by selecting back button 508 to change a se- 
lected characteristic. Completion of the port configura- 
tion may be achieved by hitting finish button 512. 
[0039] Additional details of configuring the port are il- 
lustrated in Screen 516 of Fig 6. Bi-directional settings 
section 520 of screen 516 allow users to enable or dis- 
able bi-directional communications. Screen 51 6 also al- 
lows user defined timer intervals between printer con- 
figuration updates and printer status updates by filling 
in the corresponding time interval boxes 524, 528. 
[0040] It will be appreciated that the foregoing de- 
scription Is intended to be illustrative. For example, the 
focus of the descriptions has been on the transfer of data 
between printers and clients running specific Windows 
operating systems. However, other operating systems 
which use architecture similar to the described operat- 
ing systems may also implement the described inven- 
tion. As a further example, different types of printer data 
besides the examples of printer status and printer con- 
figuration data described may be transferred. 



1 . A method of updating a print driver in a print server 
comprising the operations of: 

gathering printer data, such as printer configu- 
ration and/or printer status data, from a printer 
at a printer port; 

monitoring the incoming printer configuration 
data for changes; 

recognizing the changes in printer data; and, 
saving the changes in printer data as summa- 
rized data in a spooler registry. 

2. The method of claim 1 wherein the monitoring op- 



20 



25 



30 



35 



40 



Claims 

45 



50 



55 



BNSDOCID: <EP 



1 1 78393A2_I_> 



EP 1 178 393 A2 



10 



eration further comprises: 

polling a printer to periodically gather new print- 
er data; and 

comparing data gathered in the polling opera- 
tion with stored printer data. 

3. The method of claim 1 or claim 2, wherein the mon- 
itoring operation further comprises: 

setting flags when the comparing operation de- 
termines that the new printer data does not 
match the stored printer data; and 
waking a print driver to make a printer data 
change that matches the set flag. 

4. A method of updating a print driver in a client device 
comprising the operations of: 

gathering summarized printer data, such as 
printer configuration data and/or printer status 
data, from a printer at a printer port of a print 
server; 

monitoring the incoming printer configuration 
data at the print server for changes in the con- 
figuration data; and, 

updating a print server registry of the print serv- 
er when a change in summarized configuration 
data occurs. 

5. The method of claim 4 further comprising the oper- 
ation of updating a client device print registry when 
a change in summarized printer data occurs. 

6. The method of claim 4 or claim 5 wherein the trans- 
ferring operation occurs using a server thread that 
determines configuration options from the server 
registry and transfers the configuration options to 
the client device. 

7. The method of claim 6 wherein the transfer of the 
configuration options occurs using an operating 
systems object. 

8. A system to output printed documents comprising: 

a printer to output convert electronic signals in- 
to a printed document, the printer having a con- 
figuration state that corresponds to a particular 
period in time; 

a first client device that receives an input and 
transmits print signals to define a document to 
be printed on the printer, the first client device 
including a local print registry that maintains the 
configuration states of the printer; 
a second client device that receives a second 
input and transmits print signals to define a sec- 
ond document to be printed on the printer; and 
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a print server coupled to the first client device 
and the second client device, the print server 
including a print server registry that maintains 
the configuration states of the printer. 

9. The system of claim 8 wherein data in the print serv- 
er registry is regularly transferred to the local regis- 
try of the first client and a second local registry of 
the second client. 

10. The system of claim 9 wherein the transfers occur 
when polling of the first client and polling by the sec- 
ond client determines that a change in configuration 
states of the printer has occurred. 

1 1 . A computer program adapted to carry out the steps 
of gathering printer data, such as printer configura- 
tion and/or printer status data, from a printer at a 
printer port; 

monitoring the incoming printer configuration 
data for changes; 

recognizing the changes in printer data; and, 
saving the changes in printer data as summa- 
rized data in a spooler registry. 

1 2. A computer program adapted to carry out the steps 
of gathering summarized printer data, such as print- 
er configuration data and/or printer status data, 
from a printer at a printer port of a print server; 

monitoring the incoming printer configuration 
data at the print server for changes in the con- 
figuration data; and, 

updating a print server registry of the print serv- 
er when a change in summarized configuration 
data occurs. 
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